【レポート】RDRA + JavaによるレジャーSaaSプロダクトの要件定義と実装のシームレスな接続 #jjug_ccc #jjug_ccc_c

#Java

#DDD

とばち

2022.06.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンサル部のとばち（@toda_kk）です。

本記事は、2022年6月19日に開催されたオンラインカンファレンス JJUG CCC 2022 Spring にて行われたセッション「RDRA + JavaによるレジャーSaaSプロダクトの要件定義と実装のシームレスな接続」のレポートです。

JJUG CCCは、例年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。

このセッションでは、アソビュー社 CTOである江部隼矢さんによって、レジャー業界におけるSaaSプロダクトをRDRAによって要件定義・実装していったプロセスを解説してくれる内容になっています。

セッション概要

レジャー業界のSaaSを提供するアソビューで実践するRDRA + Javaによる要件定義と実装の流れを紹介します。

ソフトウェア開発において、規模の大きなプロジェクトであればあるほど要件定義と実装の断絶を起こしがちで、正しいあるべき姿が失われていくことにより長期的に開発コストが積み上がっていくことが多々あるとおもいます。

アソビューでは、RDRAとDDDのエッセンスを用いて、ビジネス要求を高い網羅性と整合性を持って整理し、長期的に要件と実装が一体となった状態を保っていくことにチャレンジしています。

本発表では実際のレジャー施設向けSaaS開発プロジェクトを具体例として紹介します。まだ道半ばのプロジェクトではありますが、一つの事例として参考にしていただければと思います。

スピーカー

江部隼矢さん

セッション資料

セッション動画

セッションレポート

事例プロジェクト

全国のレジャー施設約10,000施設向けの業務支援SaaS開発プロジェクト
背景
- 10年間にわたる戦略・事業モデル変化による、事業・業務・システム間の実態乖離
- 肥大化した手運用業務
- レガシー化・ブラックボックス化したシステム
長期的な開発プロセスを視野に入れた刷新プロジェクト
- 新規参画の開発者が早く活躍できるような環境を整備していきたい。
- 陳腐化していくだけのドキュメントは作りたくない。
- 事業実態とシステムの乖離を長期的に抑えたい。
- あらゆるステークホルダーとの共通理解のベースを作りたい。
RDRA + DDDによる開発を採用。

RDRAとは？

「ラドラ」と読みらしい。　
モデルベースの用件定義手法で、システムのWhatとWhyをRDRAのレイヤーに沿って定義していく。
- システム価値／システム外部環境／システム境界／システムの4レイヤーで表現する。
- 右から左に対して依存関係があり、Whyを定義していく。

補足: RDRAについて参考になりそうなリンク

プロジェクト準備

プロジェクト憲章の作成と合意
- しっかり言語化／ざっくり認識合わせの部分を分けた上で、経営陣・部門長のレイヤーで合意。
要求事項の洗い出しと構造化
- 各組織における新プロジェクトへの期待をヒアリングする。
- ヒアリングした結果を戦略要求／業務要求／IT要求／達成基準に構造化する。
- 構造化した上で、それぞれ高／中／低で優先順位をつけ、1stスコープを定める。

要件定義セッション

コアメンバー全員で議論しながら、その場でどんどんRDRAモデルを作り上げていく。
RDRAは通常、ダイアグラムで表現していく。
今回は共同作業のしやすさを重視して、Google Spreadsheetで構造管理した。

システム価値

システムの価値を享受する人や外部システムを考え、システムの輪郭を捉える。
- アクター／外部システムという2つの要素を洗い出していく。
- 既存システムの刷新であり既存の業務に精通していたため、比較的容易に整理できた。
業務・BUC・アクティビティと情報
- 全社のバリューチェーンに沿って、業務／Business Use Case（BUC）／アクティビティという3階層で整理する。
- まず、業務をビジネスドメインの単位で洗い出す。
- 次に、各ビジネスドメインに対してどのようなビジネス価値を生み出す必要があるのか（BUC）、そして生み出したビジネス価値をどのように届けるか（アクティビティ）、という観点で整理する。
- 同時に、それぞれの階層でどういった情報が扱われるのかを整理する。
- 洗い出して整理した情報がそのままユビキタス言語になっていく。
状態モデル
- 情報は基本的に状態をもつので、各情報がどのような状態を保つのかを洗い出し、Use Case（UC）と状態の遷移について明らかにする。
- 状態の遷移とUCを紐づける作業を行うことで、足りないUCに気づくことができる。
バリエーション・条件
- バリエーション: コンテキストごとに存在するビジネスの区分
  - 例えば、「チケット」というコンテキストでは「着券種別」というバリエーションによって、システムの振る舞いが変わってくる。
- いわゆるビジネスルールを「条件」としてUCごとに明確化する。
各要素の関連付け
- 人や外部システムが、どうシステムと関わるかをUCとつなげて定義する。
  - 例えば、基本情報の登録画面という要素があり、それは登録担当者というアクターが操作するものになる、といった関連付けを定義する。
  - 外部システムとの連携も定義していく。
情報 => 概念モデル
- 複雑な仕様に関しては、オブジェクトモデルで具体例を当てはめて、成立するかどうか検証する。
- UC複合表によって、システム全体の輪郭が明確になっていく。
- アクターがあるのに画面がないなど、システムの過不足といった不整合を洗い出すことができた。

実装への落とし込み

RDRAモデルと3層 + ドメイン層へのマッピング
- プレゼンテーション層／アプリケーション層／インフラストラクチャ層 + ドメイン層というよくあるアーキテクチャを想定。
業務／BUC／アクティビティ／UCをアプリケーション層にマッピングした。
- Package／Subpackage／Service
コンテキストをドメイン層にマッピングした。
- コンテキストをPackage、情報をSubpackageで表現。
- 状態モデルが持つ状態をEnumで表現。
- 条件をDomain Objectで表現。
インフラストラクチャ層
- コンテキストと情報のモデルから、データモデルを生成し、データソースとして表現。
- 外部システムについても、Clientとして表現。
- Package／Subpackage／Controller／Form
プレゼンテーション層
- UC複合表で洗い出した画面（Figmaでデザインしたもの）をUIで表現。
- 外部システムからの呼び出しイベントを、APIのインターフェースとして表現。
これらは、あくまでもとっかかりとしてのガイドラインであり、実装を進めながら粒度を最適化していく方針。

以降のイテレーション

ビジネスの変化はRDRAを起点に取り組んでいく。
Javaの実装とRDRAを直接比較するのは、開発が進むとなかなかつらくなってくるので、JIGを利用して出力したドキュメントによって整合性をチェックする。

補足: JIGについて参考になりそうなリンク

JIGはJavaのバイトコードから一覧やダイアグラムを出力するツールであり、上述したような3層 + ドメインモデルのアーキテクチャが想定されています。
dddjava/jig
- 「JIGはコードでの設計を支援するツールです。思い浮かんだ設計をコーディングすればいい感じに可視化される世界を目指しています。」とのことです。
ビジネスロジックのモデリングと実装 - ソフトウェア設計を考える
JIGを利用したモデリングのすすめ - Adwaysエンジニアブログ

まとめ

手応えを感じたところ
- 実際のシステムの輪郭を構造化して表現できた。
- 要件が構造化されているので、プログラムコードへの落とし込みとマッピングがスムーズであり、新規参画した開発者のキャッチアップも容易にできそう。
- 記法が統一されているので、誰でもメンテナンスできる。ドキュメントの陳腐化を防ぐことができる。
今後の課題
- ビジネス要件の根拠となるものと、RDRA間のマッピングをどうするかが課題になりそう。
  - 事業計画や営業で管理している契約、顧客要望、ビジネスルールなどをRDRAでどのようにマッピングしていくか。
  - ビジネスサイドも含めた組織全体に対して、プロジェクトチームからRDRAモデルへの共通理解を広げていく必要があると感じている。
- 開発体制として、組織変更といった会社全体の大局に呑まれずにRDRAと実装の整合性を合わせていく文化やルール作りが重要。
- 現在は要件定義を行い実装を進めている段階だが、今後の実装が進んでいくにつれて詳細なノウハウを蓄積して、情報発信をしていきたい。

質疑応答

今回は刷新プロジェクトへの適用だったが、新規プロダクト開発のような不確実性の高い場合にも有効な手法になりそうか？
- 新規の開発プロジェクトだと、何を作っていくのかという整理を、実際にビジネスを企画する人たちと一緒に実施していくことが重要だと思う。
このような開発プロセスで想定外だったことはあるか？
- 「プロセスそのものに対する想定外はなかったですが、セッションベースで要件定義をすすめるので毎回参加者の時間はかなり取られるのは念頭にいれたほうがいいなと思いました。」